利用する立場で快適なSlackのスラッシュコマンドを求めて改善に着手してみた

Slackにて業務用のスラッシュコマンドを用意していたものの、実際に使ってみて何となくコマンドに振り回されている感じがありました。具体的に気に入らない部分を出してみて、どうすると快適になりそうかを考えつつ手を入れた点について書いてみました。

#Slack

haoyayoi

2021.01.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

使い勝手のいいSlackのスラッシュコマンドは業務の円滑進行にとても役立ちます。ただ、他のやりとりが間に挟まらないようにするため、私個人としてはSlackBotや自身のDMチャンネル上にしています。

とある社内向けスラッシュコマンドの利便性向上を試みました。エラーになった場合は処理用のAWS Lambda関数ログをCloudWatch上で調査するのですが、単純にバグやネットワーク経路が原因のエラーなのか、コマンド要件に沿わないパラメータを渡されたとしてのエラーなのか、区別のつかないケースが多かったためです。

改善を図る際に検討した項目とそのうち具体的に行った項目を、記録として残してみることにします。

よいスラッシュコマンドとは

ものすごくふわっとした問いになりますが、個人的には以下の要件で考えています。

読み取れる実行結果がレスポンスとしてかえされること
コマンドによる実行だと後からわかること
正常に完了しなかった理由が推測できること
コマンド名の誤認を起こさないこと
必要な引数に所謂Secretな文字列を求められないこと

満たしていない場合、1番目はバグとして、2番目は要件不足として扱われる可能性があります。3番目は作業工数の関係で割愛されやすいところです。4番目はその後追加される無関係なスラッシュコマンドが災いする可能性もあり、もらい事故的な面もありそうです。5番目はインシデントに繋がりかねません。

よいスラッシュコマンドへ昇華させてみる

上記を踏まえて対処していくことにします。

読み取れる実行結果がレスポンスとしてかえされること

他のチャンネルへ通知するつもりがされていない場合は、チャンネルを間違えていないか確認します。投稿したいのに上手く行っていない場合はAPIの利用を見直します。投稿した内容が人に解釈できない場合は、大体はmarkdownの失敗だったり、文字化けだと思われます。確認方法が検討つかない場合は、以下のプレビューを利用しましょう。

コマンドによる実行だと後からわかること

実行コマンドをSlackに投稿して残したい場合、API Gateway経由でAWS Lambda関数に渡しているのならeventから取得するように指定可能です。

>from urllib.parse import parse_qs


def invoke(event, context):
    payload_raw = event['body']
    payload = parse_qs(payload_raw)
    command = payload['command']
    text = payload['text']
    print(f"実行されたコマンド: {command} {text}")

取得したcommandとtextの組み合わせをSlackに通知するとよいでしょう。